![[アップデート] Amazon Aurora PostgreSQL でも遂にリードレプリカのローカル書き込み転送機能がサポートされました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-7e1a533ff5b5a6a8eb5d4ae82bacdcd6/5845157a3c941213d245ec7cdf7358e8/amazon-aurora)
[アップデート] Amazon Aurora PostgreSQL でも遂にリードレプリカのローカル書き込み転送機能がサポートされました
2024.10.18いわさです。
Amazon Aurora MySQL にはリードレプリカの書き込み転送機能というものがあります。
通常データベースでリードレプリカを導入する場合はアプリケーション側がライターとリーダーのどちらへクエリを送信するのか意識する必要があります。
またライターへの書き込み直後にリーダーから読み込みを行おうとすると、レプリケーションラグによってまだ書き込み内容が反映されていない場合があり、一貫性のある読み取りが必要な場合はライターから読み取りを行わなければいけない場合などがアプリケーション側で色々と考慮が必要です。
Aurora MySQL の書き込み転送機能を有効化すると、リーダーに対して書き込み操作を行うことが出来ます。
これによってアプリケーションはリーダーエンドポイントに対して書き込みも読み取りを行うのみでよくなり、またパラメータモードの調整によって読み取り一貫性のレベルをコントロールすることも出来ます。
この一貫性のレベルによっては待機時間が増える場合がありアプリケーション応答性に影響が出る場合もあるのですが、書き込みが低頻度で一貫性のある読み取りが必要なワークロードなど場合には適していると言われています。
この便利そうなローカル書き込み転送機能ですが、これまでは PostgreSQL はサポートされていなかったのですが今朝のアップデートで使えるようになったとアナウンスがありました。
PostgreSQL ではグローバルデータベースに限っては書き込み転送がサポートされていたのですが、今回ローカルクラスター内での書き込み転送がサポートされたことで採用出来るワークロードが非常に広がったと思います。
有効化して使ってみましたので紹介します。
クラスターの設定で有効化するだけ
Aurora クラスターの作成・変更で有効化操作を行うだけなので非常に簡単ではありますが、注意点としてはエンジンバージョンの制限があります。16.4、15.8、14.13 以上である必要があります。
サポートされているエンジンバージョンであれば次のように「リードレプリカの書き込み転送」が表示されると思います。デフォルトは無効化されているのでチェックして有効化しましょう。
既存クラスターであれば、設定タブのこちらから有効になっているか確認可能です。
CONSISTENCY MODE パラメータの調整
Aurora MySQL の時と同じで読み取り一貫性のレベルをクラスターパラメータで調整出来ます。
apg_write_forward.consistency_modeというパラメータです。
MySQL のリリース当時はデフォルト OFF だったのですが、PostgreSQL ではデフォルトがsessionとなっていました。すぐに使える状態ですね。
どのパラメータが良いかは以下の公式ドキュメントを参考にしてください。
ここはどうしてもトレードオフになる部分でして、一貫性のレベルを強くすると待機時間が大きくなる可能性があります。うまいこと調整してみてください。
DML の適当なクエリを投げてみる
有効化したら後は使ってね。というくらいではあるのですがせっかくなので何か書き込み転送してみますか。
事前にライターでテーブルを作成しておきます。
% psql -h hoge1018postgres-instance-1.cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com -U postgres
Password for user postgres:
psql (14.11 (Homebrew), server 16.4)
WARNING: psql major version 14, server major version 16.
Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=> create table fuga (col1 integer, col2 TEXT);
CREATE TABLE
で、接続先をリーダーインスタンスに切り替えて、こちらから INSERT してみましょう。
普通はリーダーなので無理ですよと怒られますよね。成功しました。
% psql -h hoge1018postgres-instance-1-ap-northeast-1a.cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com -U postgres
Password for user postgres:
psql (14.11 (Homebrew), server 16.4)
WARNING: psql major version 14, server major version 16.
Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=> insert into fuga values (1, 'aaa');
INSERT 0 1
ライターインスタンでも読み取ってみると取得出来ました。
クライアントからリーダーインスタンスを経由して書き込みがされていますね。
% psql -h hoge1018postgres-instance-1.cpnu9ipu74g4.ap-northeast-1.rds.amazonaws.com -U postgres
Password for user postgres:
psql (14.11 (Homebrew), server 16.4)
WARNING: psql major version 14, server major version 16.
Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=> select * from fuga;
col1 | col2
------+------
1 | aaa
(1 row)
なお、内部的にはリーダーインスタンスからライターインスタンスに書き込み操作が転送されている形で、ユーザー一覧を確認してみるとrdswriteforwardというユーザーが存在していることが確認出来ます。
postgres=> select * from pg_user;
usename | usesysid | usecreatedb | usesuper | userepl | usebypassrls | passwd | valuntil | useconfig
---------------------+----------+-------------+----------+---------+--------------+----------+----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
postgres | 16409 | t | f | f | f | ******** | infinity |
rdswriteforwarduser | 16416 | f | f | f | f | ******** | |
rdsadmin | 10 | t | t | t | t | ******** | infinity | {TimeZone=utc,log_statement=all,log_min_error_statement=debug5,log_min_messages=panic,exit_on_error=0,statement_timeout=0,role=rdsadmin,auto_explain.log_min_duration=-1,temp_file_limit=-1,search_path=pg_catalog,stats_fetch_consistency=snapshot,default_tablespace=,idle_session_timeout=0,pg_hint_plan.enable_hint=off,default_transaction_read_only=off,idle_in_transaction_session_timeout=0}
(3 rows)
制限事項もある
書き込み操作であればなんでも許可されているわけではありません。
基本的には INSERT, DELETE, UPDATE などの DML 程度と考えておくと良さそうです。
例えばリーダーでの DDL はサポートされておらず CREATE TABLE や ALTER TABLE などは失敗します。
postgres=> create table fuga (col1 integer, col2 TEXT);
ERROR: cannot execute CREATE TABLE in a read-only transaction
DETAIL: CREATE TABLE is not supported for write forwarding
postgres=>
他 ANALYZE や VACUUM もリーダーからは不可です。
アプリケーションが必要とする書き込み操作のみがサポートされており、メンテナンス周りは対象外と考えておくと良さそうですね。
パフォーマンスの確認
この書き込み転送ですが、非常に便利そうですがパフォーマンスどうなん？というが一番気になるところだと思います。
こればかりはパラメータ設定しつつアプリケーションで使って評価するしかないのですが、評価に役立ちそうなものとして今回のアップデートで書き込み転送に関する CloudWatch メトリクスが追加されています。
例えばリーダーとライター間のレイテンシに関しては次のようなメトリクスが追加されており、書き込みが多すぎてリーダーの待機が顕著な場合などはメトリクスからも確認出来るようになっています。
このあたりを組み合わせながら評価してみるのが良いですね。
さいごに
本日は Amazon Aurora PostgreSQL でも遂にリードレプリカのローカル書き込み転送機能がサポートされたので使ってみました。
MySQL のローカル書き込み転送がサポートされた時は少し注目されていた方も多かったのではないかと記憶しています。
PostgreSQL でも使いたいなと考えていた方もいらっしゃるはずなので、ぜひ試してみてください！
![[レポート] 目的に応じたマネージドデータベースの使い方が学べるワークショップ「Build a web-scale application with purpose-built databases & analytics [REPEAT]」 #DAT403-R1 #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
